Previously, when a snippet that had already been rendered was modified and the new version failed to compile, the renderer got stuck on a bad state until that snippet was fixed: the rendered image of other snippets wasn't updated when they were modified, and the last rendered image of the bad snippet would keep being shown. Additionally, if by the time the bad snippet was fixed any other snippets were different from before the bad snippet stopped compiling, those snippets would get re-rendered and their previous image would get stuck on the screen.

This patch fixes this issue: now when a snippet is modified and it stops compiling its rendered image is properly cleared and the rest of the snippets are unaffected.

Before:

After:

After a long time of debugging i found out that under the situation i mentioned, the module.private.image_api.clear() call in the following for loop was silently erroring out, which lead to the images not being properly cleared (since only the local copy of the images table was partly updated, but the original version actually used by the rest of the renderer was never updated with the modified local copy). After using pcall() to get the error from the image_api.clear() call, the actual error was E5560: nvim_buf_is_valid must not be called in a lua loop callback, which according to the stacktrace comes from image.nvim.

I'm not sure why the nio.scheduler() call is needed because it's already called before any of this code runs (right before the renderer is called) and it's weird that it's only needed in this specific case, but through trial and error it seems to be needed again after the call to module.required["core.integrations.treesitter"].execute_query() (right before where it's currently at) to avoid the error